1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for improving Web services description generation and maintenance including the formation of WSDL files.
2. Description of the Related Art
The term “web services” can be viewed as a technology for engaging in business relationships (e.g., buying and selling) in a partially or wholly automated fashion over a network such as the Internet. FIG. 1 shows a web services model 100 that includes a registry 101, a service provider 102 and a service consumer 103. A service consumer 103, or “service requester”, is generally understood to be an entity that seeks and (in cases where a suitable web service is found) uses a particular web service through a network 104.
The registry 101 includes listings of various “available” services, and, may assist the service consumer 103 in searching for a suitable service provider based on the web servicing needs of the service consumer 103. A service provider 102 is the provider of one or more web services that can be accessed over the network 104. Because of the vast expanse of the Internet and interest in automated business engagements, many registries, service consumers and service providers may be in operation at any instant of time.
Presently, the responsibilities of the most prevalent registry function 101 that is associated with the web services effort are defined in various Universal Discovery, Description and Integration (UDDI) specifications provided by uddi.org. Besides providing listings of available services, a UDDI registry 101 may also make available to a service consumer 103 additional details that pertain to any particular web service such as: 1) the location of the web service (e.g., its URI specified by a specific network destination address or name); 2) the capabilities of the web service (e.g., specific methods that are supported by the web service and that may be called upon by the service consumer), and, 3) communication semantics needed for invoking the web service through the network 104 (e.g., the structure of a messaging format and/or protocol needed to properly communicate with the web service).
According to one widely adopted approach, such “additional details” are described in Web Services Definition Language (WSDL) text documents written in extensible Markup Language (XML). Here, for example, for each web service that the registry 101 maintains a listing of, the registry 101 also maintains a WSDL document that describes the location, capabilities and communication semantics of the web service. Presently, a WSDL document for a particular web service is expected to include an “abstract interface” description of the web service (which includes the web service's methods and the data passed between the web service provider and web service consumer) and a “concrete implementation” description of the web service (which includes specific protocol and data format specifications for communicating with the web service (referred to as a “binding”) and the location of the web service (referred to as a “port”)).
According to another widely adopted approach, with respect to the actual communication that occurs between the service consumer 103 and the service provider 102, such communication is implemented through an exchange of Simple Object Access Protocol (SOAP) text messages written in XML.
WSDL files are created in the XML format that describe a Web service provider's services as a set of endpoints (or ports) operating on messages containing either document-oriented or procedure-oriented information. For example, a SOAP message may be directed toward a particular port of a Web services provider from a remote client. FIG. 2 illustrates an exemplary WSDL file.
A WSDL file generally contains information for types 201, messages 203, port types 205, bindings 207, and services 209 supported by the Web service provider. From this WSDL file a client may determine how to communicate with a Web service and what functionality the Web service provides.
A type describes for data type definitions using a type system. For example, the type system may be XSD (XML Schema Descriptor). In the example of FIG. 2, the type 201 is an XSD file called patents.xsd. This file is located on the Web service provider's server (here bstz.com).
Messages in a WSDL file are described abstractly and define the data being communicated between endpoints or ports. For example, the message 203 is called “GetStatus” and provides the patent status in the body of the message.
Port types are abstract collections of operations supported by a Web service. Each operation describes a function supported. The port type 205 illustrated describes the operation “GetStatus” including the input and output message format to be adhered to.
Bindings are concrete protocols and define the particular data format for a particular port type. In the example, the binding 207 associates the “GetStatus” operation with a SOAP message.
A port is defined by binding a network protocol and message format. A collection of these ports define a service. The service 209 ties the “PatentAppSoaPBinding to the port “PatentAppPort.”
Current WSDL document generation requires manual intervention to describe the Web service. Either a program such as GLUE is run or the WSDL file is generated manually. In either case, these WSDL files cannot be automatically generated based upon a request to the service provider.
Additionally, WSDL files were generated from web service artifacts such as Virtual Interface, WSD and web-services-deployment-descriptor which were inside a web service archive. The WSDL generation was done at the deployment time of a web service. Accordingly, when request is made for WSDL visualization, the WSDL simply read from the file system. In this approach it is impossible for a configuration to be edited/removed/added at runtime without editing the web service artifacts, updating the archive, and redeploying it.